Digital watermarking of content is very well known. The content may comprise any type of digital data or digital signals, and may include one or more of audio data, image data, video data, textual data, multimedia data, a web page, software products, security keys, experimental data or any other kind of data. There are many methods for performing digital watermarking of content but, in general, they all involve adding a watermark to an item of content. This involves embedding, or adding, one or more watermark symbols (or a watermark codeword or payload data) into the original item of content to form a watermarked item of content, from which the watermark symbols are decodable by a suitable corresponding watermark decoder. The watermarked item of content can then be distributed to one or more users (or recipients or receivers).
The method used for adding a watermark codeword to an item of content depends on the intended purpose of the watermark codeword. Some watermarking techniques are designed to be “robust”, in the sense that the embedded watermark codeword can be successfully decoded even if the watermarked item of content has undergone subsequent processing (be that malicious or otherwise). Some watermarking techniques are designed to be “fragile”, in the sense that the embedded watermark codeword cannot be successfully decoded if the watermarked item of content has undergone subsequent processing or modification. Some watermarking techniques are designed such that the difference between the original item of content and the watermarked item of content is substantially imperceptible to a human user (e.g. the original item of content and the watermarked item of content are visually and/or audibly indistinguishable to a human user). Other criteria for how a watermark is added to an item of content exist.
Digital forensic watermarking, often referred to as fingerprint watermarking or simply fingerprinting, is increasingly being used to trace or identify a particular copy of content that had been provided to one (or more) users/receivers, to thereby identify those one (or more) users/receivers. This could be used, for example, to trace users who have “leaked” their content in an unauthorized manner (such as an unauthorized online distribution or publication of content). For this type of watermarking process, respective watermark codewords are assigned to each legitimate/authorized receiver/user. Each of the receivers/users receives, or is provided access to, a copy of the original item of content with their respective watermark codeword embedded therein. Then, if an unauthorized copy of the item of content is located, the watermark codeword can be decoded from that item of content and the receiver/user that corresponds to the decoded watermark codeword can be identified.
FIG. 1 of the accompanying drawings schematically illustrates an example system in which fingerprint watermarking may be deployed. In particular, a content provider 100 is arranged to provide, or supply, content to one or more receivers 102.
The content provider 100 may be arranged to communicate with a receiver 102 over a network (not shown), so that the content provider 100 may provide the content to the receivers 102 over the network. In this case, the network may be any kind of network suitable for transmitting or communicating the content from the content provider 100 to the receivers 102. For example, the network could comprise one or more of a local area network, a wide area network, a metropolitan area network, the internet, a wireless communications network, a cable network, a digital broadcast network, a satellite communication network, a telephone network, etc. The content provider 100 may then communicate with a receiver 102 over the network via any suitable communication mechanism/protocol in order to communicate the content (and any other necessary information, such as conditional access data or digital rights management data) from the content provider 100 to the receiver 102. However, it will be appreciated that other communication scenarios are possible. For example, the content provider 100 may provide to a receiver 102 a physical medium (such as a CD, DVD, BluRay disc, etc.) storing the content. All that is important is that the content provider 100 may provide content to the receivers 102.
The content provider 100 may be any system with one or more processors arranged to provide content to the receivers 102. For example, the content provider 100 may comprise a headend system of a digital broadcast system or of a cable network system, or the content provider 100 may comprise one or more servers for transmitting, or providing access to, content over the internet.
Likewise, each receiver 102 may be any device comprising one or more processors that are arranged to receive and process content received from the content provider 100. For example, the receivers 102 may comprise one or more of a set-top-box, a personal computer, a mobile telephone, a games console, etc.
In FIG. 1, three receivers 102 are shown, but it will be appreciated that the content provider 100 may provide content to any number of receivers 102.
One of the receivers 102 is shown in more detail in FIG. 1. In particular, the receivers 102 have an associated decryption module 110 and an associated decoder module 120, as discussed below. Whilst the decryption module 110 and the decoder module 120 are shown as being part of the receiver 102, the decryption module 110 and/or the decoder module 120 may be separate from the receiver 102. For example, the decryption module 120 may be implemented, in whole or in part, within a secure decryption device (such as a smart card) removably coupled to the receiver 120. The decoder module 120 may be implemented in a separate device (such as a television set) communicably coupled to the receiver 120.
The content provider 100 may provide the content in encrypted form to the receivers 102, i.e. the content provider 100 may encrypt the content (or at least a part thereof) before communicating the content to the receivers 102. The content provider 100 may then provide one or more decryption keys to the receivers 102—the decryption module 110 of a receiver 102 is configured to use a decryption key that that receiver 102 has been provided with to decrypt an amount of encrypted content that that receiver 102 has received. In this way, access to the content may be controlled, insofar as a receiver 102 will only be able to decrypt and access content if that receiver 102 has been provided with a suitable decryption key.
There are numerous mechanisms by which decryption keys may be provided to receivers 102. For example, in digital broadcast systems, entitlement control messages (ECMs) and entitlement management messages (EMMs) are used as a mechanism for providing content decryption keys to receivers 102. As the use of ECMs and EMMs is well-known, it shall not be described in detail herein. However, in brief, control words CWs (which are decryption keys or decryption information for enabling a receiver 102 to decrypt a corresponding amount of encrypted content) are transmitted to receivers 102 in ECMs. The CWs are themselves sent in encrypted form in the ECMs. To enable a receiver 102 to access/decrypt an ECM in order to access and use the CW contained therein, the receiver 102 is provided with, and receives, an EMM. The EMM contains a decryption key DK1 that enables the receiver 102 to decrypt the CWs in the ECMs (and hence obtain access to the encrypted content). The decryption key DK1 is itself sent in encrypted form in the EMM. The EMM is targeted at a specific receiver 102 (or a specific set of receivers 102), in that the decryption key DK1 is encrypted in the EMM using an encryption key EK2 that corresponds to a decryption key DK2, or product key, that is known only to that specific receiver 102 (or to that specific set of receivers 102) and that can be used to decrypt the encrypted decryption key DK1. In this way, only a receiver 102 that has access the product key DK2 can access the decryption key DK1 contained in the EMM. In this way, control is provided over which particular receivers 102 can and cannot access encrypted content.
Other ways of communicating a decryption key to a receiver 102 may be used—for example, the receiver 102 (or an operator thereof) may contact the content provider 100 to request a decryption key (for example, requesting a suitable password over the telephone).
The content itself may be encoded using a suitable coding scheme (or standard or format). The content may have been encoded by the content provider 100, or the content provider 100 may have received already-encoded content from another source (not shown in FIG. 1). The coding scheme itself could, for example, be a data compression scheme which enables more efficient communication of the content from the content provider 100 to the receivers 102. For example: if the content comprises video data, then that video data may be encoded via any suitable video coding scheme, such as MPEG2 or MPEG4 or H264; if the content comprises audio data, then that audio data may be encoded via any suitable audio coding scheme, such as MPEG1 audio, MP3 or AAC; if the content comprises webpages, then the webpages may be encoded via HTML; if the content comprises image data, then that image data may be encoded via any suitable image coding scheme, such as JPEG, BMP, TIFF, etc. Many different coding schemes are know and the above are merely examples. The decoding module 120 of the receiver 102 is configured to decode (or interpret) content that has been encoded by one or more coding schemes. For example, if the receiver 102 is intended to process video data, then the decoder module 102 may be arranged to carry out MPEG2 decoding or MPEG4 decoding or H264 decoding; if the receiver 102 is intended to process audio data, then the decoder module 102 may be arranged to carry out MPEG1 decoding or MP3 decoding or AAC decoding; if the receiver 102 is intended to process webpages, then the decoder module 102 may be arranged to carry out HTML decoding; etc. Again, many other types of decoding processing for other coding schemes are known and could be implemented by the decoding module 120 to decode content encoded according to that coding scheme.
The content provider 100 provides encoded content, some or all of which has been encrypted, to the receivers 102. The receivers 102 use their decryption modules 110 to perform a decryption process to access (or at least try to access) encoded content; the receivers 102 also use their decoder modules 120 to decode decrypted content.
Once the content has been decrypted and then decoded, it may be output as necessary, for example, to a user via a display/monitor/screen and/or one or more audio speakers or to a storage medium to be recorded and stored thereon.
An example fingerprint watermarking process is described in European patent application EP2341708, the entire disclosure of which is incorporated herein by reference. FIG. 2 of the accompanying drawings schematically illustrates, at a high level, this fingerprint watermarking process. This fingerprint watermarking process could be applied to the example system described above with reference to FIG. 1, with the content provider 100 of FIG. 1 carrying out the fingerprint watermarking process of, and comprising the modules depicted in, FIG. 2.
In FIG. 2, there is an initial quantity of data 200 to be transmitted from the content provider 100 to a receiver 102. A portion P of data is selected from the initial quantity of data 200. The initial quantity of data 200 could, for example, be a packetized elementary stream (PES) for a digital broadcast signal, with the portion P being one of the packets in the packetized elementary stream. However, it will be appreciated that the initial quantity of data 200 may be any other form of data and/or the portion P be any other segment/section/part of the initial quantity of data 200.
A version generation module 210 generates a plurality of different versions of the portion P. In FIG. 2, n different versions of the portion P, labelled P1, P2, . . . , Pn, are generated. Each version Pi (i=1, 2, . . . , n) may be formed, for example, by watermarking a copy of the portion P via a watermarking process WMi to embed a corresponding payload (or watermark data or codeword) into the copy of the portion P. The particular manner by which the modifications, or the watermarking, is performed by the version generation module 210 is unimportant, insofar as it only matters that the n different versions can be distinguished from each other by an appropriate decoder/detector (such as a watermark decoder). However, it is preferable if the modifications/watermarks are robust and imperceptible to a human user.
Each of the modified versions P1, P2, . . . , Pn is then encrypted by an encryption operation E implemented by an encryption module 220. Each modified version Pi is encrypted using a corresponding encryption key Ki to form a corresponding encrypted portion E(Pi,Ki) (i=1, 2, . . . , n). For each encryption key Ki, there is a corresponding decryption key DKi which can be used to decrypt the encrypted portion E(Pi,Ki) to produce the modified portion Pi. As will be appreciated, given the nature of encryption algorithms, performing the decryption operation on an encrypted portion E(Pi,Ki) using a key other than the corresponding decryption key DKi (e.g. trying to carry out decryption using a key DKj where i≠j) will simply produce noise or random data.
In FIG. 2 and the subsequent drawings, data that is encrypted and data that has been encrypted and then incorrectly decrypted (so that it still remains encrypted) is shown in dotted-boxes.
A multiplexer 230 then combines or multiplexes the set of n encrypted portions E(Pi,Ki) (i=1, 2, . . . , n) and data from the initial quantity of data 200 other than the selected portion P. In particular, the original content portion P is replaced in the initial quantity of data 200 by the set of n encrypted portions E(Pi,Ki) (i=1, 2, . . . , n) to form an output quantity of data 202.
The output quantity of data may then be provided to a plurality of receivers 102 by a transmission module (not shown in FIG. 1) of the content provider 100. Each receiver 102 is provided with just one decryption key DKa from the set of decryption keys DK1, DK2, . . . , DKn. The decryption module 110 of a receiver 102 uses the decryption key DKa provided to that receiver 102 to try to decrypt each of the n encrypted portions E(Pi,Ki) in the quantity of data 202 that the receiver 102 has received. The encrypted portion E(Pa, Ka) formed using an encryption key Ka corresponding to the decryption key DKa provided to the receiver 102 is decrypted correctly, so that the receiver 102 has access to the corresponding modified version Pa. However, when the receiver 102 performs the decryption operation on each of the other encrypted portions using the decryption key DKa, the decryption operation simply outputs an amount of noise or random data. EP2341708 describes how, by suitably packaging the encrypted portions into the initial quantity of data 200 to form the output quantity of data 202, the error handling functionality implemented by the decoder module 120 of the receiver 102 essentially ignores, or removes, this noise or random data—i.e. the decoder module 120 will only use and output content that has been correctly decrypted from the encrypted portion E(Pa,Ka) that corresponds to the decryption key DKa provided to the receiver 102 and the decoder module 120 will skip over the other encrypted portions that do not correspond to the decryption key DKa provided to the receiver 102.
A plurality of portions located at different places within the initial quantity of data 200 may be handled this way (only one is shown in FIG. 2). Each receiver 102 may then be provided with a specific set of decryption keys (namely, for each portion, the receiver 102 is assigned a decryption key to enable the receiver 102 to decrypt just one of the modified versions of that portion). The resulting content output by the decoder module 120 of a receiver 102 will then contain the specific modified content portions that correspond to the specific set of decryption keys assigned to that receiver 102. In this way, content can be traced back to a particular receiver.
In the above-described fingerprint watermarking process, the encrypted portions E(Pi,Ki) (i=1, 2, . . . n) were formed using the same encryption operation (or algorithm) E but with different keys Ki (i.e. Ki≠Kj for 1≤i<j≤n). Additionally, or alternatively, the encryption operations used to generate the encrypted portions E(Pi,Ki) (i=1, 2, . . . , n) may vary from portion to portion. In other words, for 1≤i<j≤n, an encryption operation Ei may be used to generate one encrypted portion Ei(Pi,Ki) whilst a different encryption operation Ej may be used to generate another encrypted portion Ej(Pj,Kj)—in this case, the keys Ki and Kj for these encrypted portions may be different from each other or may be the same as each other. The receiver would implement a decryption operation (or algorithm) Di corresponding to one of the encryption operations Ei. As will be readily understood, using the decryption operation Di on an encrypted portion Ej(Pj,Kj) (j≠i) that has been generated using an encryption operation Ej that does not correspond to that decryption operation Di will result in the decryption operation Di outputting an amount of noise or random data (in a similar manner to performing decryption using an incorrect decryption key). Thus, different encryption operations may be used in the process shown in FIG. 2 in place of, or in addition to, the use of different encryption keys. In general, then, all that is required is that a plurality of encrypted portions are produced, where each encrypted portion is encrypted differently (by virtue of the choice of encryption key and/or encryption operation) from each of the other encrypted portions. In other words, one modified portion is encrypted with a corresponding “encryption process” different from the encryption process used to encrypt the other modified portions. Here, the term “encryption process” relates to the pair made up of (a) the encryption operation/algorithm used and (b) the encryption key used, so that two encryption processes can differ in terms of their encryption algorithm and/or their encryption key. Similarly, an encryption process will have a corresponding decryption process that is made up of the pair comprising (a) a corresponding decryption operation/algorithm and (b) a corresponding decryption key.
Unfortunately, the error handling/concealment relied upon in the above-described method is often not specified in the various standards (e.g. the data coding standards, such as the MPEG2 standard, or the data communication standards, such as the DVB standards). For example, when the portions used are packets of a PES, then the processing carried out by a decoder module 120 in respect of wrongly decrypted PES packets is generally not specified in the various standards. Hence some decoder modules 120 (particularly older ones) may implement a different operation when they receive a PES packet that does not start with an expected/specified PES packet start pattern (such as the pattern 0x00000001 as laid out in the MPEG2 standards). This means that some receivers 102 (and their decoder modules 120) may attempt to process the information contained in the wrongly decrypted content portions instead of skipping over or ignoring those wrongly decrypted content portions. This may, at best, result in quality degradations of the decoded data, but this could also lead to a crash of the decoder module 120 itself.